The present invention is generally directed to USB device redirection in a virtual desktop infrastructure (VDI) environment. USB device redirection generally refers to making a USB device that is connected to a client accessible within a virtual desktop as if the USB device had been physically connected to the virtual desktop. In other words, when USB device redirection is implemented, a user can connect a USB device to his or her client terminal and the USB device will function as if it had been connected to the server.
FIGS. 1 and 2 and the following description will provide a general overview of how USB device redirection can be implemented in accordance with some embodiments of the present invention. In FIG. 1, a computing system 100 is depicted as including a number of client terminals 102a-102n (referenced generally herein as client(s) 102) in communication with a server 104 via a network 106. Server 104 can be configured to support a remote session (e.g., a remote desktop session) wherein a user at a client 102 can remotely access applications and data at the server 104 from the client 102. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) and the Citrix® Independent Computing Architecture (ICA).
Client terminal 102 may represent a computer, a mobile phone (e.g., smart phone), a laptop computer, a thin client terminal, a personal digital assistant (PDA), a portable computing terminal, or a suitable terminal or device with a processor. Server 104 may represent a computer, a laptop computer, a computing terminal, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable terminal with a processor.
Client 102 may initiate a remote session with server 104 by sending a request for remote access and credentials (e.g., login name and password) to server 104. If server 104 accepts the credentials from client 102, then server 104 may establish a remote session, which allows a user at client 102 to access applications and data at server 104. During the remote session, server 104 sends display data to client 102 over network 106, which may include display data of a desktop and/or one or more applications running on server 104. The desktop may include, for example, icons corresponding to different applications that can be launched on server 104. The display data allows client 102 to locally display the desktop and/or applications running on server 104.
During the remote session, client 102 may send user commands (e.g., inputted via a mouse or keyboard at client 102) to server 104 over network 106. Server 104 may process the user commands from client 102 similar to user commands received from an input device that is local to server 104. For example, if the user commands include mouse movements, then server 104 may move a pointer on the desktop running on server 104 accordingly. When the display data of the desktop and/or application changes in response to the user commands, server 104 sends the updated display data to client 102. Client 102 locally displays the updated display data so that the user at client 102 can view changes at server 104 in response to the user commands Together, these aspects allow the user at client 102 to locally view and input commands to the desktop and/or application that is running remotely on server 104. From the perspective of the client side, the desktop running on server 104 may represent a virtual desktop environment.
Windows I/O uses a layered architecture where device drivers are on a device stack. In a basic model, the top of the stack is the file system. Next is the volume manager, followed by the disk driver. At the bottom of the device stack are the port and miniport drivers. When an I/O request reaches the file system, it takes the block number of the file and translates it to an offset in the volume. The volume manager then translates the volume offset to a block number on the disk and passes the request to the disk driver. When the request reaches the disk driver it will create a Command Descriptor Block (CDB) that will be sent to the SCSI device. The disk driver imbeds the CDB into a structure called the SCSI_REQUEST_BLOCK (SRB). This SRB is sent to the port driver as part of the I/O request packet (IRP).
The port driver does most of the request processing including providing timing services for requests, enforcing queue depth (making sure that a device does not get more requests that it can handle), and building scatter gather arrays for data buffers. The port driver interfaces with a driver called the miniport. The miniport driver is designed by the hardware manufacturer to work with a specific adapter and is responsible for taking requests from the port driver and sending them to the target logical unit number (LUN). The port driver calls the HwStorStartlo( )function to send requests to the miniport, and the miniport will send the requests to the LUN. When the request is complete, the miniport will call StorPortNotification( )with the NotificationType parameter value set to RequestComplete, along with a pointer to the completed SRB.
When a request is sent to the miniport, the port driver will put the request in a pending queue. When the request is completed, it is removed from this queue. While requests are in the pending queue they are timed. There is one timer per logical unit and it is initialized to −1. When the first request is sent to the miniport the timer is set to the timeout value in the SRB.
The timer is decremented once per second. When a request completes, the timer is refreshed with the timeout value of the head request in the pending queue. So, as long as requests complete the timer will never go to zero. If the timer does go to zero, it means the device has stopped responding. In response, the port driver logs an error and takes corrective action by trying to reset the unit. When the unit is reset, all outstanding requests are completed with an error and they are retried. When the pending queue empties, the timer is set to −1 which is its initial value.
FIG. 2 is a block diagram of a virtual device infrastructure (VDI) environment 200 which can implement this type of functionality when a USB mass storage device is redirected from a client 102 to a server 104 over a remote session. As shown, while client 102 has established a remote session with server 104, a USB mass storage device 240 is connected to client 102. In accordance with embodiments of the present invention, client 102 can be configured to redirect device 240 over the remote session so that the device is accessible on server 104. Proxy 210 on client 102 and agent 250 on server 104 can be configured to establish and maintain the remote session to enable this redirection.
FIG. 2 provides a general overview of the primary components that can be employed to redirect mass storage device 240 at the disk level. This technique can be referred to as disk level redirection and is distinguished from general USB redirection in that the redirection occurs at the disk level rather than at the USB device level. In particular, client 102 can include a disk driver stack 220 that includes a disk driver 220a, a USB storage driver 220b, and a USB hub driver 220c. As is known in the art, USB storage driver 220b and USB hub driver 220c can implement the USB protocol to enable communication with device 240 as a USB mass storage device. Disk driver 220a, which in some embodiments may be an instance of the disk.sys process, can function to service read/write requests and to abstract the underlying USB storage and hub drivers 220b, 220c. 
On the server side, a corresponding disk driver 282, which may be another instance of the disk.sys process, may sit below a file system stack 280 to receive and convert file system requests to disk requests (e.g., by creating a CDB and embedding it in an SRB) and to pass these disk requests (e.g., IRPs and associated SRBs) to a virtual disk enumerator 260 at the bottom of the device stack. It is noted that a volume manager is not shown in this figure for simplicity. Virtual disk enumerator 260 functions to virtualize mass storage device 240 on server 104 (as represented by virtual mass storage device 290). This virtualization is accomplished by routing the disk requests to agent 250 which will forward them over the remote session to proxy 210, down through disk driver stack 220, and to mass storage device 240 where they can be fulfilled. Corresponding responses can then be routed in a reverse direction towards virtual disk enumerator 260 and up through disk driver 282, file system stack 280, operating system 170, and ultimately to an application 270 that originated the request.
Virtual disk enumerator 260 can implement the port driver and miniport driver functionality described above. In particular, virtual disk enumerator 260 can implement the timer functionality for determining when an SRB has timed out, and, when a timeout occurs, can implement functionality to retry the outstanding requests.
One problem that exists when a mass storage device is redirected over a high latency network such as the internet is that the remote session can be disconnected briefly due to various factors such as congestion, high latency, packet loss, etc. Such temporary disconnections can be a result of client-side or server-side disturbances. When a brief disconnection occurs, the agent and proxy can restore the remote session so that the impact on the user experience is minimized
However, during such disconnections, including very brief disconnections, a redirected device will be disconnected from the server. If the redirected device is a mass storage device this disconnection can substantially disrupt the user experience. For example, if the user was in the process of copying a file from a redirected mass storage device to the server when a brief session disconnection occurs, the mass storage device will be disconnected from the server resulting in any progress being lost. When the session is restored, the mass storage device will be reconnected. However, the copying process will have to be restarted. Therefore, if 95% of a 10 MB file had been copied prior to the disconnection, the 9.5 MB of the file that had already been copied will have to again be copied. Accordingly, even if the session is seamlessly reestablished after a disconnection, it will still appear to the user that the copying of the file is taking a long time to complete.